Uwierzytelnienie i autoryzacja

Uwierzytelnienie i autoryzacja dostępu do usług serwera FHIR bazuje na standardzie OAuth 2.0 i metodzie zgodnej z “Client Credentials Grant”. W wyniku uwierzytelnienia się i autoryzacji dostępu do usług serwera FHIR, system zewnętrzny Usługodawcy (klient) pozyskuje z Systemu P1 (serwera autoryzacji) TOKEN DOSTĘPOWY. Warunkiem uzyskania TOKENU DOSTĘPOWEGO jest posiadanie aktualnego certyfikatu do uwierzytelnienia danych, wystawionego przez Centrum Certyfikacji P1. TOKEN DOSTĘPOWY wymagany jest każdorazowo przy przekazaniu żądania wykonania operacji na serwerze FHIR. TOKEN DOSTĘPOWY umieszczany jest w nagłówku Authorization (“Authorization” - “Bearer ‘otrzymany z serwera autoryzacyjnego TOKEN DOSTĘPOWY”). TOKEN DOSTĘPOWY obejmuje dane autoryzacyjne Usługodawcy, w tym uwierzytelniony identyfikator Usługodawcy oraz jego rolę w Systemie P1.

Autoryzacja dostępu do danych serwera FHIR

Dostęp do danych serwera FHIR do obsługi EKOK możliwy jest dla wszystkich podmiotów uczestniczących w KSK.

Przebieg uwierzytelnienia i autoryzacji do usług serwera FHIR

Uwierzytelnienie systemu zewnętrznego Usługodawcy (klienta) realizowane jest z użyciem metody private_key_jwt przedstawionej w OpenID Connect 1.0. W procesie uwierzytelnienia i autoryzacji dostępu do usług serwera FHIR CEZ, system zewnętrzny Usługodawcy (klient) przygotowuje i przekazuje do Systemu P1 (serwera autoryzacyjnego) żądanie autoryzacji zawierające TOKEN UWIERZYTELNIAJĄCY (JSON Web Token). Pozytywna odpowiedź na żądanie autoryzacji posiada status HTTP 200. W treści odpowiedzi zwrócony jest TOKEN DOSTĘPOWY (JSON Web Token).

Przygotowanie tokenu uwierzytelniającego

Struktura TOKEN UWIERZYTELNIAJĄCEGO: HEADER.PAYLOAD.SIGNATURE

Każda z sekcji z osobna zakodowana jest z użyciem Base64.

Sekcja HEADER

Sekcja nagłówka - obejmuje wskazanie na typ tokenu oraz o algorytm, którym został podpisany token:

{ “alg”: “RS256”, “typ”: ”JWT” } gdzie:

• ‘alg’ - (ang. algorithm) wskazanie na rodzaj użytego algorytmu podczas stosowania podpisu - parametr musi mieć wartość “RS256”.
• ‘typ’ - (ang. type) rodzaj przekazywanego tokenu - parametr musi mieć wartość “JWT”.

Sekcja PAYLOAD

Sekcja danych - zawiera dane, które identyfikują system zewnętrzny i pracownika wykonującego operacje w systemie zewnętrznym. Lista wymaganych parametrów w sekcji jest następująca:

• ‘iss’ - (ang. issuer) Identyfikator biznesowy (OID) podmiotu jest umieszczony w certyfikatach wydanych przez P1 – wartość parametru musi być zgodna z formatem {root}:{extension}.
• ‘sub’ - (ang. subject) identyfikator biznesowy (OID) podmiotu (Usługodawcy), który wywołuje usługi serwera FHIR. Identyfikator OID podmiotu jest umieszczony w certyfikatach wydanych przez P1.
• ‘aud‘ - (ang. audience) adres URL usługi (endpoint) serwera autoryzacji – parametr musi mieć wartość: „https://ezdrowie.gov.pl/token”.
• ‘jti’ - (ang. JWT ID) unikalny identyfikator tokenu do uwierzytelnienia - wartość parametru musi być zgodna z formatem UUID (universally unique identifier).
• ‘exp’ - (ang. expiration time) termin ważności tokenu, po upływie którego token nie może być przetwarzany – wartość parametru musi być zgodna z formatem NumericDate ze specyfikacji JWT (RFC 7519).
• ‘user_id’ - (ang. user identification) identyfikator biznesowy użytkownika (OID) – wartość parametru musi być zgodna z formatem {root}:{extension}.
• ‘user_role’ - (ang. user role) - rola użytkownika w systemie zewnętrznym – wartość parametru musi być zgodna z dopuszczalną listą ról. Zakres ról dopuszczonych do obsługi kraty e-KOK w Systemie P1:
• LEK – lekarz
• PIEL – pielęgniarka / pielęgniarz
• PROF – profesjonalista medyczny
• PADM – pracownik administracyjny
• ASYS – asystent medyczny
• FIZJO – fizjoterapeuta
• FEL – felczer
• LEKD – lekarz dentysta
• POL – położna\położny
• FARM – farmaceuta
• RAT – ratownik medyczny
• USLUGOBIORCA – usługobiorca/pacjent
• SYSWEW – podsystem P1
• DIAG – diagnosta laboratoryjny

• KOORDYNATOR – koordynator

• ‘con’ – (ang. context) – kontekst użytkownika zalogowanego do Systemu P1 w roli Asystenta Medycznego wskazanego w parametrze user_id. Kontekstem w tym przypadku jest pracownik medyczny wykonujący daną czynność medyczną. W parametrze user_id powinien się znajdować identyfikator asystenta, natomiast w parametrze ‘con’ identyfikator pracownika medycznego wykonującego daną czynność:
• w przypadku gdy user_role = ‘ASYS’, parametr jest obowiązkowy i przyjmuje postać: {OID pracownika medycznego}:{NPWZ pracownika medycznego}, wartość parametru musi być zgodna z formatem {root}:{extension}
• w przypadku gdy user_role <> ‘ASYS’, parametr nie występuje.
• ‘child_organization’ - identyfikator biznesowy (OID) miejsca udzielania świadczeń - identyfikator miejsca udzielania świadczeń/jednostki/komórki organizacyjnej (np. 2.16.840.1.113883.3.4424.2.3.3:000000001-001).

Sekcja SIGNATURE

Sekcję HEADER oraz PAYLOAD należy podpisać z wykorzystaniem klucza prywatnego systemu zewnętrznego (Usługodawcy) zawartego w certyfikacie do uwierzytelnienia danych (WS-Security), wystawionym przez Centrum Certyfikacji P1. W celu wykonania podpisu można wykorzystać bibliotekę dostępną na https://github.com/jwtk/jjwt.

Przygotowanie i przekazanie żądania autoryzacji

Przekazanie żądania autoryzacji realizowane jest metodą POST (HTTP). Nagłówek żądania autoryzacji obejmuje następujące parametry:

• “Content-Type: application/x-www-form-urlencoded” Parametry żądania autoryzacji:
• client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
• grant_type: client_credentials
• client_assertion: {TOKEN UWIERZYTELNIAJĄCY przygotowany zgodnie z powyższym opisem}.
• scope: {HYPERLINK https://ezdrowie.gov.pl/fhir-ekok} Należy zwrócić uwagę na konieczność kodowania adresu URL zgodnie ze standardem Percent-encoding.

Kody błędów odpowiedzi serwera uwierzytelnienia i autoryzacji

Kod błędu	Opis słowny	Znaczenie
400	Błędne żądanie	Podano nieprawidłowe parametry żądania.
401	Nieautoryzowany dostęp	Wskazany w żądaniu podmiot nie posiada aktywnego konta w Systemie P1 lub nie posiada żadnych uprawnienia lub token uwierzytelniający utracił ważność lub sygnatura tokenu jest niepoprawna.
422	Żądanie było poprawnie sformułowane, ale było niemożliwe do kontynuowania z powodu semantycznych błędów.	Podano nieprawidłowe parametry Tokenu autoryzacyjnego.
500	Błąd wewnętrzny	Wystąpił błąd wewnętrzny, który uniemożliwił realizację usługi.